By Tim Hudson, President, OpenSSL Corporation
For organisations preparing for post-quantum cryptography, one of the biggest risks is assuming they can wait until a sufficiently powerful quantum computer arrives before taking action.
Whilst it’s understandable to focus on the point when quantum computers might be able to break today’s cryptography, nobody can predict exactly when that will happen. A more useful question is much simpler: if you had to change your cryptography, how long would it take? For many organisations, the answer is uncomfortable. Identifying where cryptography is used, assessing dependencies and introducing alternatives could take years, particularly in complex environments.
Encryption and other cryptographic technologies are built into almost every part of modern IT. They protect communications, verify identities and safeguard sensitive information. They are also deeply embedded in applications, infrastructure, connected devices and software supplied by other organisations. They work so reliably that organisations rarely need to think about them. Until they need to change them.
Mapping your dependencies should be the starting point
The first stage of post-quantum preparation isn’t choosing a new algorithm. It is understanding what you already have.
Where is cryptography being used? Which algorithms are involved? What information are they protecting? How long does that information need to remain confidential? Which systems depend on them? Which elements can you control directly, and which rely on suppliers?
For a small technology environment, answering those questions might be relatively straightforward. Across a large enterprise with years of accumulated infrastructure and software dependencies, it can be considerably harder.
That discovery work has value regardless of when quantum computing reaches the point that concerns cryptographers. An organisation that understands its cryptographic dependencies is better prepared to respond when standards change, algorithms are retired or vulnerabilities emerge. Post-quantum cryptography is exposing a broader resilience issue: organisations need to become better at changing cryptography.
New standards still face real-world deployment challenges
We have already passed an important milestone. Post-quantum algorithms have moved beyond academic research into published standards and real implementations. OpenSSL Library 3.5, for example, introduced support for the NIST-standardised ML-KEM, ML-DSA and SLH-DSA algorithms. That is significant, but publishing and implementing standards does not mean the transition is finished.
The mathematics behind post-quantum cryptography is different from the mathematics underpinning established approaches such as RSA and elliptic curve cryptography. Those differences create practical engineering considerations.
Signature sizes are one example. An algorithm might offer the security properties cryptographers are looking for, but if using it dramatically increases the amount of data that needs to move through an existing protocol, that matters.
Performance matters too. So does interoperability with systems that will not all migrate at exactly the same time. Security cannot exist only on paper. Cryptography has to work inside the infrastructure people actually use.
Why cryptographic scrutiny matters
There is still disagreement within the cryptographic community about aspects of the post-quantum transition. I don’t think organisations should be surprised by that.
Cryptographers challenge assumptions. They examine standards closely and look for weaknesses. When technology may eventually protect enormous amounts of sensitive information, scrutiny is healthy.
One of the practical questions is whether organisations should move entirely to new post-quantum algorithms or combine them with established classical cryptography.
Hybrid approaches allow both to be used together. For organisations that want the protection offered by a new post-quantum approach without relying on it alone, that can be an attractive option during the transition. Different organisations will make different decisions.
OpenSSL’s approach is not to pick favourites between published national or international standards. We implement standards and give users choices. That allows organisations to evaluate their own circumstances rather than being forced into a single answer.
Today’s encrypted data could become tomorrow’s exposure
There is another reason some organisations may need to think about migration sooner than others. Sensitive information does not stop being valuable simply because it is encrypted today.
An attacker can collect encrypted information now and retain it. If technology capable of defeating the cryptography protecting that information becomes available later, data that still has value could become exposed.
The significance of that risk depends heavily on the information involved. Data that becomes irrelevant after a few hours is very different from government, healthcare or commercial information that may need to remain confidential for decades.
This is why a universal migration date isn’t particularly useful. Organisations need to understand their own information, infrastructure and risk.
Building systems that can adapt
If post-quantum migration teaches us anything, I hope it is that changing cryptography should not be an extraordinary event. Algorithms will change again, and the technologies we trust today will eventually be replaced.
Organisations therefore need the ability to identify where cryptography is used and change it without rebuilding enormous parts of their infrastructure every time. That is cryptographic agility, and it may ultimately be one of the most valuable outcomes of the post-quantum transition.
The organisations best prepared for the quantum era won’t necessarily be those that rushed to deploy a particular algorithm first. They will be the ones that understood their dependencies, tested new approaches carefully and built systems capable of adapting as the technology develops.
The next challenge is putting post-quantum security into practice
With standards and implementations now available, the difficult questions are increasingly about deployment. How will new algorithms perform within existing infrastructure? Which systems should organisations prioritise? And how can they make changes without creating more technical debt?
Those questions require input from more than cryptographers. Developers need to understand the challenges facing security teams, while researchers need to hear from those implementing new approaches. Organisations also need to understand what these standards mean for the technology they already depend on.
Events such as this year’s OpenSSL Conference in Prague provided an opportunity to bring these different perspectives together. But the conversation is far from over. As the focus moves from developing standards to applying them to real-world environments, new questions and challenges will emerge. These discussions will remain important well beyond the conference itself.
We still cannot say when a quantum computer capable of breaking today’s cryptography will arrive. But organisations do not need that answer to start preparing. They can begin by understanding their systems and building the ability to change them when necessary.
Quantum computing still has an uncertain timetable. The preparation work is concrete, and it can start now.
